All committers have signed the CLA.

While this PR gets most of the way there to getting the dedicated server running, an issue is still present which blocks the server from running on Windows: the FancyModLoader language providers aren't getting discovered by FML, leading to a crash as the minecraft system mod (provided by the FML Minecraft language provider) is missing.

In brief, I've determined the root cause to be the use of File.separatorChar in FML's FileUtils#matchFileName. File.separatorChar's value depends on the running operating system -- per its javadoc, it is / (forward slash) on UNIX systems, and \ (backslash) on Microsoft Windows systems.

However, the legacy classpath is always written using / forward slashes in Util#getArtifacts. This means that the dedicated server is able to match the file names of the language providers (passed as the fml.pluginLayerLibraries system property) against the classpath only on UNIX systems as File.separatorChar is / there.

I'm currently in the process of testing a fix in FancyModLoader for this. The PR author has consented to me or another maintainer updating this PR with the new FML version once that has been tested, merged, and published.

I've updated this PR with the version bump for FancyModLoader, as said above. I've tested the change locally, and it works -- the dedicated server now boots up fully.

This looks like the wrong solution to the problem. If I understand correctly, you basically fixed it by forcing all the modules into the legacy classpath instead. a COMPLETELY incorrect solution.

It's the same solution the other launch setups I looked at (userdev server+client, prod client) use, so I assumed that it was the correct one. If this PR is not usable please close it, I will not be able to work on this for the next 1.5 weeks.

Please do not merge this in the current state or anything like it. this looks completely wrong. I will be investigating tomorrow.

I can say at the very least that duplicating the artifacts from the pluginLayerLibrary and gameLayerLibrary configurations to the installer configuration manually is not the way to go. These deps are already installed yet not properly added to the clas spath in thewin_args.txt / unix_args.txt files that the server uses at startup. (This is a mistake from me when I implemented the feature initially at 5am 3 weeks ago.) The team will be looking into this with a close eye and our own fixes/cleanup in the next coming days. Thanks.

OK. The fundamentals were correct - i was misinterpreting the classpath discussion. However, you can't futz with the installer configuration, because that breaks the client. You have to fix the server install to merge the LayerLibrary files into the CLASS_PATH, as well as fixing the ignore.